| Oracle TimesTen Replication - TimesTen to TimesTen開発者および管理者ガイド
リリース6.0 B25769-02 |
|
 前へ |
 次へ |
レプリケーション・スキームを作成して、マスターおよびサブスクライバのデータ・ストアの特定の設定を定義できます。この項では、スキームの作成時に、マスター・データ・ストアとサブスクライバ・データ・ストア間に定義可能な関係について説明します。レプリケーション・スキームの作成方法については、「レプリケーション・スキーム」を参照してください。
マスターとサブスクライバ間の関係を定義する場合は、次に示す内容のいくつかについて考慮する必要があります。
図1.1に、マスター・データ・ストア全体をサブスクライバにレプリケートする全体レプリケーション・スキームを示します。また、マスター・データ・ストアとサブスクライバ・データ・ストアを様々な組合せで設定して、マスター・データ・ストア内の一部の表要素を選択してサブスクライバにレプリケートできます。
図1.5に、選択レプリケーションの例を示します。左側のマスター・データ・ストアでは、同じ要素を選択して複数のサブスクライバにレプリケートしています。一方、右側のマスターでは、サブスクライバごとに異なる要素をレプリケートしています。
図1.5 複数サブスクライバへの選択要素のレプリケート
また、図1.6に示すように、選択レプリケーションの別の使用方法として、1つのサブスクライバに要素をレプリケートするように複数のマスター・データ・ストアを設定する方法もあります。このサブスクライバ・データ・ストアは共通のバックアップ・データ・ストアとして使用されます。
図1.6 複数のマスターによる1つのサブスクライバへのレプリケート
ここまでは、マスター・データ・ストアが1つ以上のサブスクライバ・データ・ストアに更新を送信する単方向レプリケーションについて説明してきましたが、データ・ストアを双方向に動作させて、各データ・ストアがマスターおよびサブスクライバの両方であるように設定することもできます。
双方向レプリケーションには、次の2つの基本的な使用方法があります。
分割ワークロード設定では、各データ・ストアが一部の表要素に対してはマスターとして、他の表要素に対してはサブスクライバとして機能します。
図1.7の例について考えてみます。ここでは、Chicagoのアカウントはデータ・ストアAで処理され、New Yorkのアカウントはデータ・ストアBで処理されます。
図1.7 分割ワークロードの双方向レプリケーション
一般ワークロード設定では、各データ・ストアが同じ表要素に対してマスターおよびサブスクライバの両方として機能します。いずれのデータ・ストアのアプリケーションでも要素の更新が可能で、行った更新は他方のデータ・ストアにレプリケートされます。このタイプの設定は、マルチマスターと呼ばれる場合があります。
一般ワークロード・スキームには次の2つの基本タイプがあります。
図1.8に、ホット・スタンバイ構成を示します。この構成は、単方向レプリケーションと同様に単純ですが、データ・ストアの障害が発生した場合に簡単で高速なリカバリを可能にします。2つのマスター・データ・ストアが存在しますが、アプリケーションは、障害が発生するまで一方のデータ・ストアのみを更新します。障害が発生した時点で、他方のデータ・ストアに切り替えます。
ユーザーはデータ・ストアAで処理を行い、サブスクライバとして機能するデータ・ストアBに更新がレプリケートされます。データ・ストアAで障害が発生した場合、ユーザーは、データ・ストアBにすでに設定されているアプリケーションのコピーにリダイレクトすることができます。データ・ストアAは、リカバリ後、サブスクライバとして機能できます。
図1.8 ホット・スタンバイ構成
図1.9に、分散ワークロード設定を示します。ユーザーは、他方のデータ・ストアでマスターおよびサブスクライバの両方として機能する、各データ・ストアの複製アプリケーションにアクセスします。
図1.9 分散ワークロード設定
データ・ストアが分散ワークロード設定でレプリケートされる場合、個々のユーザーが同じ行を同時に更新し、互いにその更新をレプリケートする可能性があります。アプリケーションでは、このような更新が発生しないこと、発生した場合でもその競合が許容可能であること、または「レプリケーション競合の検出および解消」で説明している競合解消メカニズムを利用して、競合をうまく解消できることが保証されている必要があります。
サブスクライバは、レプリケート対象の更新をマスターから受信して自身のサブスクライバに渡すプロパゲータとして機能するように定義できます。
プロパゲータは、より低い帯域幅のネットワーク接続（イントラネットでのサーバー間の接続など）でのレプリケーション・パフォーマンスの最適化に有効です。たとえば、図1.10に示す直接レプリケーション設定について考えてみます。この設定では、マスターがイントラネット接続を介して4つのサブスクライバに直接レプリケートします。この方法でネットワーク接続を介して各サブスクライバにレプリケートすると、ネットワークの帯域幅が効率的に使用されません。
図1.10 マスターによるネットワーク上の複数サブスクライバへのレプリケート
最適なパフォーマンスを実現するために、図1.11に示す設定について考えてみます。この構成では、マスターは、ネットワーク接続を介して1つのプロパゲータにレプリケートします。その後、このプロパゲータが、自身のローカル・エリア・ネットワーク上の各サブスクライバに更新を転送します。
図1.11 マスターによるネットワーク上の単一プロパゲータへのレプリケート
また、プロパゲータは、多数のサブスクライバにレプリケートする必要があるマスター・データ・ストアを含む設定でレプリケーション・ロードを分散する場合にも有効です。例えば、図1.12に示すように、マスターで、12のサブスクライバに直接レプリケートするより、3つのプロパゲータにレプリケートするほうがより効率的です。
図1.12 プロパゲータを使用した多数のサブスクライバへのレプリケート
図1.13に、アクティブ・マスター・データ・ストア、スタンバイ・マスター・データ・ストアおよび4つの読取り専用サブスクライバ・データ・ストアで構成されたアクティブ・スタンバイ・ペア構成を示します。
図1.13 アクティブ・スタンバイ・ペア
アクティブ・スタンバイ・ペアは、SQL文CREATE ACTIVE STANDBY PAIRを使用して作成します。CREATE ACTIVE STANDBY PAIR文では、アクティブ・マスター・データ・ストア、スタンバイ・マスター・データ・ストア、およびそのデータ・ストアを構成する表とキャッシュ・グループを指定します。
アクティブ・スタンバイ・ペアでは、2つのデータ・ストアがマスターとして定義されます。1つは、アクティブ・マスター・データ・ストアで、もう1つはスタンバイ・マスター・データ・ストアです。アクティブ・マスター・データ・ストアは、アプリケーションで直接更新されます。スタンバイ・マスター・データ・ストアは、直接更新できません。スタンバイ・マスター・データ・ストアは、アクティブ・マスター・データ・ストアからの更新を受信し、それらの変更を最大62の読取り専用サブスクライバ・データ・ストアに伝播します。この設定では、スタンバイ・マスター・データ・ストアがサブスクライバ・データ・ストアより常に先行し、アクティブ・マスター・データ・ストアで障害が発生した場合は、スタンバイ・データ・ストアに即時にフェイルオーバーできます。
1つのマスター・データ・ストアのみが、特定の時間にアクティブ・マスター・データ・ストアとして機能できます。ttRepStateSetプロシージャによって、マスター・データ・ストアの役割が割り当てられます。アクティブ・データ・ストアで障害が発生した場合、ユーザーは、ttRepStateSetプロシージャを使用して、障害が発生したデータ・ストアをスタンバイ・データ・ストアとしてリカバリする前に、スタンバイ・マスター・データ・ストアの役割をアクティブに変更できます。また、ユーザーは、新しいスタンバイ・マスター・データ・ストアでレプリケーション・エージェントを起動する必要があります。
スタンバイ・マスター・データ・ストアで障害が発生した場合は、アクティブ・マスター・データ・ストアでサブスクライバに変更を直接レプリケートできます。スタンバイ・マスター・データ・ストアは、リカバリ後、アクティブ・マスター・データ・ストアに接続し、スタンバイ・マスター・データ・ストアの停止またはリカバリ中にサブスクライバに送信された更新を受信します。アクティブ・マスター・データ・ストアとスタンバイ・マスター・データ・ストアで同期が取られている場合、スタンバイ・マスター・データ・ストアは、サブスクライバへの変更の伝播を再開します。
アクティブ・スタンバイ・ペアの設定の詳細は、「アクティブ・スタンバイ・ペア」を参照してください。アクティブ・スタンバイ・ペアの管理方法の詳細は、「アクティブ・スタンバイ・ペアの管理」を参照してください。
